# lii.cc Redesign Notes

## General Principles

The lii.cc website redesign is an opportunity to draw the author's mind map. It
should not only present works made by Stefano Cossu / LII and their
relationships with relevant entities, but also project an idea of the world
from the point of view of the author and his line of work. The perspective is
that of *gesamtkunstwerk* where the "comprehensive artwork" is the shaping of
one's behavior and life.

## Design Principles

The site will be developed to be used in the Internet 3.0, and to be
experienced as the Internet 1.0.

The UX goal is to deliver contents in an extremely plain interface, which is
very fast loading and easily readable. If possible, minimal to no Javascript
should be involved across the site. CSS should be used wisely and unobtrusively
to give shape to specific concepts not otherwise expressible in a normal text
flow.

## High Level Site Structure

- Index page: no splash, just index of contents
- Work catalog pages
  - Pinhole works
  - Cameras
  - Non-pinhole projects
  - External projects
  - Writings
  - Links to other sites that cannot be integrated (nobigdreaming, etc.)
- Informational pages
  - Theory (overall and in relation to the technology)
  - Bio
  - Links, etc.

The index page represents the subject of the site, either LII or SC. The
index represents the principal attributes of the subject.

## Technology

### Content Storage

#### Solution #1

All textual contents are in one or more RDF files, in which each named graph
represents one distinct resource (work, agent, exhibition, etc.). The files
are kept in a Git hash tree which takes care of versioning. This git tree may
be released on the public domain and must be separate from the code repository.

Large binary files such as images and audiovisual media may be stored using
git-annex. Experimenting needed.

#### Solution #2

All contents are stored in Lakesuperior. The presentation application has read-
only access to the LS instance, which gets updated by a separate application.

This will rely on much less tested software but it would be a great opportunity
to real-world test LS with a very small data set. It is also a quite clean
and usable solution for both RDF and non-RDF data.

A clear separation of CMS and presentation must be achieved. I.e. the web
server should be carefully configured to block all write requests and any
access outside the `/ldp` endpoint from the presentation app. The latter also
creates an additional layer of protection by not exposing LS directly to the
end user.

An even better solution would be to use the Python API to avoid any direct HTTP
interaction with LS.

Contents are presented in HTML and alternatively in plain text format. The
source is stored in Markdown as a blank node or separate resource with a
`dc:format` property set to `text/markdown` and a `rdf:value` property set to
the Markdown content.

### Identifiers

All resources are identified by opaque URIs. They are minted separately.

Base namespace for all resource identifiers is TBD. It can be a subdomain of
an already owned DN, e.g.:

  - `http://data.lii.cc/model#`
  - `http://data.cossu.cc/model#`
  - `http://data.knowledgetx.com/model#`

Or variations thereof.

## Content

### Semantic Model

The way content is modeled is crucial to offering a particular view not only of
the author's work, but also of the world around it. It should present a
mind map of evolving concepts, in which artifacts, events, people and documents
are intertwined in a "cluster of influence". Think Hildegard von Bingen.

The modeling should not be too pedantic or stiffly ontological: things should
not be presented primarily as e.g. "human made objects" or such. This ontology
is built around a presentational system.

At the same time, each resource that can be independently displayed as a Web
document, no matter how trivial (e.g. a material or a language), should have
its own interpretive context, in the form of a description and icon. These
interpretive elements constitute the bond between the artwork and its
environment. They also highlight the creative role of each element in the
making of an artwork or artifact.

The initial semantic model should contain very basic properties, possibly
confined to `dcterms`. Mapping to Linked.Art may be considered, depending on
the complexity of the task.

### Legacy Content Migration

Legacy contents of lii.cc are stored in a relational database. The relevant
records should be translated into RDF according to an established model. A
Python script will be very likely necessary to migrate all contents.

### Content Creation

To enter new content, it may be necessary to develop a basic command line
utility to generate RDF files from CSV files representing some fixed properties
of each resource, e.g. title, body, article type, etc. Existing content can be
modified manually with a text editor. A CMS should not be necessary.

#### Multilingual Content

All contents will be in US English and Italian. Language is negotiated via user
agent headers and cookies.

### Content Presentation

#### Textual Content

The front end part of the software is a semi-static site: server-side code
(Python/Flask) is used to transform RDF into HTML. No database
or triplestore is involved at any stage (however one may eventually be needed
if the data set grows considerably). Varnish cache is placed in front of
the web server (Nginx).

Content requested as `text/html` will be rendered from source RDF by means of
templates. The default format is `text/turtle`. `application/ld+json` and other
RDF serialization formats may be supported by upstream libraries (RDFLib with
all probability)

HTML contents should be rendered in HTML5 compliance using semantic tags.

#### Audiovisuals

All audiovisual media will be delivered via IIIF. IIPImage will be used as the
image server. No fancy viewer is used on the site—images linked in the
site pages are statically resized within a given bounding box.

A "Gallery View" is dynamically generated from semantics of a RDF document.
This gallery consists of an independent HTML page with a stack of images and
legends.

#### Presentation Models

Some reference models of presentation:

- https://craigslist.org/ A very long-lived and successful model of Web 1.0
  minimalism and efficiency that has changed little or nothing in many years.
- http://suckless.org/ Reflects the group's philosophy. No JS across the whole
  site.

## Experience

In line with the author's pursuit for the *Gesamtkunstwerk*, The site should
have a very plain look, with minimal styling but very concise and clean content
presentation.

The navigation should be rich with connections yet not overwhelming (the data
set is very small anyways). Pointers to the home page and main categories
should always be present. The flow should emphasize the multiple connections
between the nodes. References to other Web (RDF and not) resources should be
used where appropriate.

This site should not be a praise of Linked Data but should
use Linked Data for a scope, as well as interpreting its core concepts and
taking them to expected directions. Technology should be an instrument to
convey profound currents.

An interpretive layer is present in each and every individual resource, as
mentioned above in the "Content Model" section. This allows to make the
navigation of completely random resources (there should indeed be a persistent
menu item linking to a random resource) a more interesting experience.

Pages may present incomplete data, especially connections, in a mix of random
and biased choices guided by algorithms. This is to support both the
interpretive nature of the site as well as the *dérive* experience. The
algorithms used for the biased "suggestions" should reflect the author's point
of view in a concealed fashion.
